您可能会发现有InnoDB利于以下原因的表格：

对于InnoDB您可以在您的应用程序代码中应用的特定调优技术，请参见 第8.5节“优化InnoDB表”。

本节介绍使用InnoDB表格时的最佳做法 。

发表SHOW ENGINES声明以查看可用的MySQL存储引擎。寻找 DEFAULT在InnoDB行。

mysql> SHOW ENGINES;

或者，查询 INFORMATION_SCHEMA.ENGINES表格。

mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES;

如果InnoDB不是您的默认存储引擎，您可以InnoDB通过--default-storage-engine=InnoDB 在命令行中default-storage-engine=innodb 定义或者 在[mysqld]MySQL服务器选项文件部分中定义的重新启动服务器 来确定数据库服务器或应用程序是否正常工作。

由于更改默认存储引擎只会在创建新表时影响新表，请运行所有应用程序安装和设置步骤以确认所有事情都已正确安装。然后练习所有的应用程序功能，以确保所有数据加载，编辑和查询功能都能正常工作。如果表依赖于特定于其他存储引擎的功能，则会收到错误; 将该 子句添加 到 语句以避免错误。 ENGINE=other_engine_nameCREATE TABLE

如果您没有仔细决定存储引擎，并且想要预览某些表在创建时如何工作InnoDB，请ALTER TABLE table_name ENGINE=InnoDB;为每个表发出命令 。或者，要运行测试查询和其他语句而不干扰原始表格，请复制一份：

CREATE TABLE InnoDB_Table（...）ENGINE = InnoDB AS SELECT * FROM other_engine_table;

要在真实工作负载下评估完整应用程序的性能，请安装最新的MySQL服务器并运行基准测试。

测试完整的应用程序生命周期，从安装到大量使用和服务器重新启动。在数据库繁忙期间终止服务器进程以模拟电源故障，并在重新启动服务器时验证数据是否已成功恢复。

测试任何复制配置，特别是如果您在主服务器和从服务器上使用不同的MySQL版本和选项。

Oracle建议InnoDB将其作为典型数据库应用程序的首选存储引擎，从单一用户维基和本地系统上运行的博客到推动性能极限的高端应用程序。在MySQL 5.7中，InnoDB是新表的默认存储引擎。

缓冲池是主存储器中的一个区域， InnoDB用于访问作为数据的缓存表和索引数据。缓冲池允许经常使用的数据直接从内存中处理，从而加快处理速度。在专用数据库服务器上，经常将高达80％的物理内存分配给InnoDB缓冲池。

为了提高高容量读取操作的效率，缓冲池分为可能包含多行的页面。为了高速缓存管理的效率，缓冲池被实现为页面的链接列表; 很少使用的数据使用LRU算法的变体超时缓存。

有关更多信息，请参见第14.6.3.1节“InnoDB缓冲池”和第14.6.3节“InnoDB缓冲池配置”。

更改缓冲区是一种特殊的数据结构， 当受影响的页面不在缓冲池中时，缓存对辅助索引页面的 更改。缓冲的变化，这可能导致从 ， 或 当页面被加载到由其他的读操作缓冲池操作（DML），将在后面合并。 INSERTUPDATEDELETE

与聚簇索引不同，二级索引通常是不唯一的，插入到二级索引中会以相对随机的顺序进行。同样，删除和更新可能会影响不相邻位于索引树中的二级索引页。稍后合并缓存更改时，受影响的页面通过其他操作读入缓冲池时，可避免从磁盘读入二级索引页面所需的大量随机访问I / O。

定期地，当系统大部分处于空闲状态或缓慢关闭期间运行的清除操作会将更新后的索引页写入磁盘。与每个值立即写入磁盘相比，清除操作可以更有效地为一系列索引值写入磁盘块。

当需要更新许多二级索引和许多受影响的行时，更改缓冲区合并可能需要几个小时。在此期间，磁盘I / O会增加，这可能会导致磁盘绑定查询的显着减速。事务提交后，更改缓冲区合并也可能继续发生。事实上，在服务器关闭和重新启动后，更改缓冲区合并可能会继续发生（请参见 第14.21.2节“强制InnoDB恢复”以获取更多信息）。

在内存中，更改缓冲区占用了InnoDB缓冲池的一部分 。在磁盘上，更改缓冲区是系统表空间的一部分，因此索引更改在数据库重新启动时保持缓冲。

缓存在更改缓冲区中的数据类型由 innodb_change_buffering 配置选项控制。有关更多信息，请参见 第14.6.5节“配置InnoDB更改缓冲”。您还可以配置最大更改缓冲区大小。有关更多信息，请参见 第14.6.5.1节“配置更改缓冲区的最大大小”。

所述自适应散列索引（AHI）允许InnoDB执行更喜欢与工作量和用于充足存储器的适当组合，系统内存中的数据库 缓冲池，在不牺牲任何事务特性或可靠性。该功能由该innodb_adaptive_hash_index 选项启用 ，或--skip-innodb_adaptive_hash_index在服务器启动时关闭 。

根据观察到的搜索模式，MySQL使用索引键的前缀构建一个哈希索引。密钥的前缀可以是任意长度，并且可能只有B树中的某些值出现在哈希索引中。哈希索引是根据需要为经常访问的索引页面构建的。

如果一张表几乎完全适用于主内存，那么散列索引可以通过直接查找任何元素来加快查询速度，从而将索引值转换为一种指针。InnoDB 有一个监视索引搜索的机制。如果 InnoDB注意到查询可以从构建散列索引中受益，它会自动执行。

对于一些工作负载，散列索引查找的加速大大超过了监视索引查找和维护散列索引结构的额外工作。有时候，保护访问自适应散列索引的读/写锁可能成为工作负载繁重的争用源，如多个并发连接。查询与 LIKE运营商和% 通配符也不会从AHI中受益。对于不需要自适应散列索引的工作负载，将其关闭可减少不必要的性能开销。因为很难提前预测此功能是否适合特定系统，请考虑使用实际工作负载来启用和禁用启用和禁用基准。MySQL 5.6和更高版本中的架构更改使适用于禁用自适应哈希索引的工作负载比早期版本更适合，但默认情况下它仍处于启用状态。

在MySQL 5.7中，自适应散列索引搜索系统是分区的。每个索引都绑定到一个特定的分区，每个分区受独立的锁存器保护。分区由innodb_adaptive_hash_index_parts 配置选项控制 。在早期版本中，自适应散列索引搜索系统受单个锁存器的保护，该锁存器在繁重的工作负载下可能成为争用点。该 innodb_adaptive_hash_index_parts 选项默认设置为8。最大设置是512。

散列索引始终基于表上现有的B树索引构建 。 InnoDB可以在为B树定义的任何密钥长度的前缀上构建一个哈希索引，具体取决于InnoDB观察到的B树索引的搜索模式。散列索引可以是部分的，仅覆盖索引经常访问的那些页面。

您可以监视自适应哈希索引的使用SEMAPHORES 以及在SHOW ENGINE INNODB STATUS命令输出部分中 使用它的争用情况。如果看到许多线程正在等待创建的RW锁存器btr0sea.c，那么禁用自适应散列索引可能会很有用。

有关散列索引性能特征的更多信息，请参见第8.3.8节“B树和散列索引的比较”。

重做日志缓冲区是保存要写入重做日志的数据的内存区域。重做日志缓冲区大小由innodb_log_buffer_size 配置选项定义 。重做日志缓冲区会定期刷新到磁盘上的日志文件。一个大的重做日志缓冲区允许大事务运行，而无需在事务提交之前将重做日志写入磁盘。因此，如果您有更新，插入或删除多行的事务，则使日志缓冲区更大可节省磁盘I / O。

该 innodb_flush_log_at_trx_commit 选项控制如何将重做日志缓冲区的内容写入日志文件。该 innodb_flush_log_at_timeout 选项控制重做日志刷新频率。

所述InnoDB系统表空间包含的 InnoDB数据字典（元数据 InnoDB-相关对象）和对于双写缓冲器，所述缓冲器改变的存储区，并撤消日志。系统表空间还包含在系统表空间中创建的任何用户创建表的表和索引数据。系统表空间被视为共享表空间，因为它被多个表共享。

系统表空间由一个或多个数据文件表示。默认情况下，ibdata1在MySQL data目录中创建一个名为named的系统数据文件。系统数据文件的大小和数量由innodb_data_file_path启动选项控制 。

有关相关信息，请参见 第14.6.1节“InnoDB启动配置”和 第14.7.1节“调整InnoDB系统表空间大小”。

所述InnoDB数据字典包括包含用于跟踪对象，如表，索引，和表中的列的元数据的内部系统表。元数据物理上位于InnoDB系统表空间中。由于历史原因，数据字典元数据在一定程度上与存储在InnoDB表元数据文件（.frm文件）中的信息重叠 。

双写缓冲区是一个位于系统表空间中的存储区域，在这个区域中，页面写入数据文件中的适当位置之前，缓冲池中的InnoDB页面被刷新InnoDB。只有在刷新并将页面InnoDB写入双写缓冲区之后，才会 将页面写入其正确的位置。如果在页面写入过程中存在操作系统，存储子系统或 mysqld进程崩溃，InnoDB可以稍后在崩溃恢复期间从双写缓冲区中找到页面的良好副本。

尽管数据总是写入两次，但双写缓冲区不需要两倍的I / O开销或两倍的I / O操作。数据作为一个大的顺序块写入到双写缓冲区本身，只需一次fsync() 调用操作系统。

在大多数情况下，默认情况下会启用doublewrite缓冲区。要禁用双写缓冲区，请设置 innodb_doublewrite为0。

如果系统表空间文件（“ ibdata文件 ”）位于支持原子写入的Fusion-io设备上，则会自动禁用双写缓冲，并将Fusion-io原子写入用于所有数据文件。由于双写缓冲区设置是全局性的，所以对于驻留在非Fusion-io硬件上的数据文件，也会禁用双写缓冲。此功能仅在Fusion-io硬件上受支持，并且仅适用于Linux上的Fusion-io NVMFS。要充分利用此功能，建议使用此innodb_flush_method设置 O_DIRECT。

撤消日志是与单个事务关联的撤消日志记录的集合。撤销日志记录包含有关如何撤消事务对聚集索引 记录的最新更改的信息 。如果另一个事务需要查看原始数据（作为一致读取操作的一部分），则从撤消日志记录中检索未修改的数据。撤销日志存在于 撤消日志段中，该日志段包含在 回滚段中。回滚段位于 系统表空间， 临时表空间和撤消表空间中。有关更多信息，请参阅 第14.7.7节“配置撤消表空间”。有关多版本控制的信息，请参见第14.3节“InnoDB多版本控制”。

InnoDB支持128个回退段，其中32个保留为临时表事务的非重做回滚段。每个更新临时表（不包括只读事务）的事务都被分配了两个回滚段，一个启用了重做的回滚段和一个非重做回滚段。只读事务只分配非重做回滚段，因为只读事务只允许修改临时表。

这留下了96个可用回滚段，每个回滚段支持多达1023个并发数据修改事务，总共限制大约96K个并发数据修改事务。96K限制假定事务不修改临时表。如果所有数据修改事务也修改临时表，则总数限制约为32K个并发数据修改事务。有关为临时表事务保留的回滚段的更多信息，请参见 临时表撤消日志。

该innodb_rollback_segments 选项定义了使用的回退段的数量 InnoDB。

每个文件表的表空间是一个单独的表空间，它是在它自己的数据文件中创建的，而不是在系统表空间中创建的。innodb_file_per_table启用该选项时，将在每个文件表格空间中创建表格 。否则，InnoDB将在系统表空间中创建表。每个每个文件表的表空间由单个.ibd数据文件表示，该数据文件默认在数据库目录中创建。

文件每表的表空间支持DYNAMIC和 COMPRESSED行格式支持诸如用于可变长度数据和表压缩的离页存储之类的功能。有关这些功能以及file-per-table表空间的其他优点的信息，请参见 第14.7.4节“InnoDB每个表文件的表空间”。

InnoDB使用CREATE TABLESPACE语法创建 的共享表空间 。常规表空间可以在MySQL数据目录之外创建，能够保存多个表，并支持所有行格式的表。

表使用或 语法添加到常规表空间 。 CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_nameALTER TABLE tbl_name TABLESPACE [=] tablespace_name

有关更多信息，请参见第14.7.9节“InnoDB常规表空间”。

撤消表空间包含一个或多个包含撤消日志的文件 。使用的撤消表空间的数量InnoDB由innodb_undo_tablespaces 配置选项定义 。有关更多信息，请参见 部分14.7.7，“配置撤消表空间”。

非压缩的用户创建的临时表和磁盘内部临时表是在共享的临时表空间中创建的。的 innodb_temp_data_file_path 配置选项定义了相对路径，名称，规格，和用于临时表空间的数据文件属性。如果未指定值 innodb_temp_data_file_path，则缺省行为是ibtmp1在innodb_data_home_dir目录中创建一个自动扩展数据文件，该 文件的名称 略大于12MB。

压缩的临时表（使用该ROW_FORMAT=COMPRESSED属性创建 的临时表）是在临时文件目录中的文件 - 每表中的表空间中创建的 。

临时表空间在正常关闭或中止初始化时被删除，并在每次启动服务器时重新创建。临时表空间在创建时接收动态生成的空间ID。如果无法创建临时表空间，则启动将被拒绝。如果服务器意外停止，则不会删除临时表空间。在这种情况下，数据库管理员可以手动删除临时表空间或重新启动服务器，该服务器会自动删除并重新创建临时表空间。

临时表空间不能驻留在原始设备上。

INFORMATION_SCHEMA.FILES提供有关InnoDB临时表空间的元数据。发出与此类似的查询来查看临时表空间元数据：

MySQL的> SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G

INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO 提供有关在InnoDB实例中当前活动的用户创建的临时表的元数据。有关更多信息，请参见 第14.15.7节“InnoDB INFORMATION_SCHEMA临时表信息表”。

MySQL的> SELECT @@innodb_temp_data_file_path;
+ ------------------------------ +
| @@ innodb_temp_data_file_path |
+ ------------------------------ +
| ibtmp1：12M：autoextend |
+ ------------------------------ +

MySQL的> SELECT FILE_NAME, TABLESPACE_NAME, ENGINE, INITIAL_SIZE, TOTAL_EXTENTS*EXTENT_SIZE 
       AS TotalSizeBytes, DATA_FREE, MAXIMUM_SIZE FROM INFORMATION_SCHEMA.FILES 
       WHERE TABLESPACE_NAME = 'innodb_temporary'\G
*************************** 1. row ******************** *******
      FILE_NAME：./ibtmp1
TABLESPACE_NAME：innodb_temporary
         ENGINE：InnoDB
   INITIAL_SIZE：12582912
 TotalSizeBytes：12582912
      DATA_FREE：6291456
   MAXIMUM_SIZE：NULL

的[mysqld]
innodb_temp_data_file_path = ibtmp1：12M：自动扩展：最大：500M

重做日志是在崩溃恢复期间使用的基于磁盘的数据结构，用于纠正由不完整事务写入的数据。在正常操作期间，重做日志将编码请求以更改 InnoDB由SQL语句或低级别API调用产生的表数据。在意外关闭之前没有完成更新数据文件的修改会在初始化期间以及接受连接之前自动重播。有关重做日志在崩溃恢复中的角色的信息，请参见第14.18.2节“InnoDB恢复”。

默认情况下，重做日志在物理上表现为一组文件，名为ib_logfile0和 ib_logfile1。MySQL以循环方式写入重做日志文件。重做日志中的数据按受影响的记录进行编码; 这些数据统称为重做。数据通过重做日志的过程由不断增加的LSN值表示。

有关相关信息，请参阅：

本节介绍由使用的锁类型 InnoDB。

TABLE LOCK table`test`.`t` trx id 10080锁定模式IX

记录锁定space id 58 page no 3 n bits 72 index`PRIMARY` table`test`.`t` 
trx id 10078 lock_mode X锁定rec，但不锁定
记录锁定，堆号2物理记录：n_fields 3; 紧凑格式; 信息位0
 0：len 4; 六千八百〇万; asc ;;
 1：len 6; 十六进制00000000274f; asc'O ;;
 2：len 7; 十六进制b60000019d0110; asc ;;

SELECT * FROM child WHERE id = 100;

（负无穷，10）
（10,11]
（11,13]
（13,20]
（20，正无穷）

记录锁定space id 58 page no 3 n bits 72 index`PRIMARY` table`test`.`t` 
trx id 10080 lock_mode X
记录锁定，堆号1物理记录：n_fields 1; 紧凑格式; 信息位0
 0：len 8; 十六进制73757072656d756d; asc supremum ;;

记录锁定，堆号2物理记录：n_fields 3; 紧凑格式; 信息位0
 0：len 4; 六千八百〇万; asc ;;
 1：len 6; 十六进制00000000274f; asc'O ;;
 2：len 7; 十六进制b60000019d0110; asc ;;

mysql> CREATE TABLE child (id int(11) NOT NULL, PRIMARY KEY(id)) ENGINE=InnoDB;
mysql>INSERT INTO child (id) values (90),(102);

mysql> START TRANSACTION;
mysql>SELECT * FROM child WHERE id > 100 FOR UPDATE;
+ ----- +
| id |
+ ----- +
| 102 |
+ ----- +

mysql> START TRANSACTION;
mysql>INSERT INTO child (id) VALUES (101);

记录锁定空间ID 31页面号3 n位72索引表'test`.`child`的`PRIMARY`
trx id 8731 lock_mode X在插入意图等待之前锁定间隙
记录锁，堆号3物理记录：n_fields 3; 紧凑格式; 信息位0
 0：len 4; 六角形80000066; asc f ;;
 1：len 6; 十六进制000000002215; asc“;;
 2：len 7; 六角9000000172011c; asc r ;; ...

在InnoDB事务模型中，目标是将多版本数据库的最佳属性 与传统的两阶段锁定相结合。默认情况下，按照Oracle的风格，InnoDB在行级别执行锁定并将查询作为非锁定一致读取运行 。锁定信息 InnoDB存储在空间中，因此不需要锁定升级。通常，允许多个用户锁定InnoDB表中的每一行或任何行的随机子集，而不会导致 InnoDB内存耗尽。

外壳> mysql test

MySQL的> CREATE TABLE customer (a INT, b CHAR (20), INDEX (a));
查询OK，0行受影响（0.00秒）
mysql> -- Do a transaction with autocommit turned on.
mysql>START TRANSACTION;
查询OK，0行受影响（0.00秒）
MySQL的> INSERT INTO customer VALUES (10, 'Heikki');
查询OK，1行受影响（0.00秒）
MySQL的> COMMIT;
查询OK，0行受影响（0.00秒）
mysql> -- Do another transaction with autocommit turned off.
mysql>SET autocommit=0;
查询OK，0行受影响（0.00秒）
MySQL的> INSERT INTO customer VALUES (15, 'John');
查询OK，1行受影响（0.00秒）
MySQL的> INSERT INTO customer VALUES (20, 'Paul');
查询OK，1行受影响（0.00秒）
MySQL的> DELETE FROM customer WHERE b = 'Heikki';
查询OK，1行受影响（0.00秒）
mysql> -- Now we undo those last 2 inserts and the delete.
mysql>ROLLBACK;
查询OK，0行受影响（0.00秒）
MySQL的> SELECT * FROM customer;
+ ------ + -------- +
| a | b |
+ ------ + -------- +
| 10 | Heikki |
+ ------ + -------- +
一排（0.00秒）
MySQL的>

SELECT COUNT（c1）FROM t1 WHERE c1 ='xyz';
- 返回0：没有行匹配。
DELETE FROM t1 WHERE c1 ='xyz';
- 删除其他事务最近提交的几行。

SELECT COUNT（c2）FROM t1 WHERE c2 ='abc';
- 返回0：没有行匹配。
UPDATE t1 SET c2 ='cba'WHERE c2 ='abc';
- 影响10行：另一个txn只提交了10行'abc'值。
SELECT COUNT（c2）FROM t1 WHERE c2 ='cba';
- 返回10：这个txn现在可以看到它刚刚更新的行。

             会议A会议B

           SET autocommit = 0; SET autocommit = 0;
时间
| SELECT * FROM t;
| 空集
| 插入t值（1，2）;
|
v SELECT * FROM t;
           空集
                                  承诺;

           SELECT * FROM t;
           空集

           承诺;

           SELECT * FROM t;
           ---------------------
           | 1 | 2 |
           ---------------------

SELECT * FROM t FOR SHARE;

SELECT * FROM parent WHERE NAME ='Jones'锁定共享模式;

SELECT counter_field FROM child_codes FOR UPDATE;
UPDATE child_codes SET counter_field = counter_field + 1;

UPDATE child_codes SET counter_field = LAST_INSERT_ID（counter_field + 1）;
SELECT LAST_INSERT_ID（）;

一个锁定读，一个 UPDATE或 DELETE一般设置纪录是在SQL语句的处理扫描每个索引记录锁定。WHERE在声明中是否存在会排除该行的条件并不重要 。InnoDB不记得确切的WHERE情况，但只知道扫描了哪些索引范围。这些锁通常是下 一个键锁，它也会在记录之前立即阻止插入“ 间隙 ”中。但是， 可以显式禁用间隙锁定，这会导致不使用下一个锁定键。有关更多信息，请参阅 第14.5.1节“InnoDB锁定”。事务隔离级别还可以影响设置了哪些锁; 请参见 第14.5.2.1节“事务隔离级别”。

如果在搜索中使用辅助索引，并且要设置的索引记录锁是独占的，则InnoDB还会检索相应的聚集索引记录并在其上设置锁。

第14.5.1节“InnoDB锁定” 介绍了共享锁和独占锁之间的区别 。

如果您没有适合您的语句的索引，并且MySQL必须扫描整个表以处理语句，则表的每一行都会被锁定，从而阻止其他用户的所有插入到表中。创建好的索引非常重要，以便您的查询不会不必要地扫描多行。

对于SELECT ... FOR UPDATEor SELECT ... LOCK IN SHARE MODE，锁定是为扫描行获取的，并且对于不符合结果集条件的行（例如，如果它们不符合WHERE条款中给出的条件），将被释放。但是，在某些情况下，行可能不会立即解锁，因为在执行查询期间，结果行与其原始源之间的关系会丢失。例如，在一个 UNION，从表中扫描（和锁定）的行可能会在评估之前插入临时表中，以确定它们是否符合结果集。在这种情况下，临时表中的行与原始表中的行之间的关系会丢失，并且后面的行在查询执行结束之前不会解锁。

InnoDB 如下设置特定类型的锁。

当相同的查询在不同时间产生不同组的行时， 所谓的幻影问题发生在事务中。例如，如果a SELECT被执行了两次，但第二次返回的是第一次未返回的行，则该行是“ 幻影 ”行。

假设表的id列上有一个索引，child并且您希望读取并锁定标识符值大于100的表中的所有行，并打算稍后更新所选行中的某一列：

SELECT * FROM child WHERE id> 100 FOR UPDATE;

查询从id大于100 的第一条记录开始扫描索引 。让该表包含id值为90和102的行。如果在扫描范围内的索引记录上设置的锁不锁定在间隙中进行的插入在这种情况下，90和102之间的差距），另一个会话可以id在101 的表中插入一个新行 。如果要在同SELECT一个事务中执行 相同的事务，则会看到一个id101 行的新行（一个 “ 幻影 ”）在查询返回的结果集中。如果我们将一组行视为一个数据项，那么新的幻像子将违反事务应该能够运行的事务的隔离原则，以便在事务处理期间它所读取的数据不会改变。

为了防止幻像，InnoDB使用称为下一个键锁定的算法，该算法结合了索引行锁定和间隙锁定。 InnoDB以这样的方式执行行级锁定，即当它搜索或扫描表索引时，它会在遇到的索引记录上设置共享锁或排它锁。因此，行级锁实际上是索引记录锁。另外，索引记录上的下一个键锁也会影响该索引记录之前的 “ 间隙 ”。也就是说，下一个键锁定是索引记录锁定，并在索引记录之前的间隔上加上间隙锁定。如果一个会话有记录的共享或排他锁R在索引中，另一个会话不能R在索引顺序中立即在间隙中插入新的索引记录 。

当InnoDB扫描索引，它也可以锁定在指数的最后一个记录之后的间隙。在前面的例子中，就发生了这种情况：为了防止在表中插入 id大于100的任何数据，设置 InnoDB的锁在id值102之后的间隙中包含一个锁 。

您可以使用下一个键锁定在您的应用程序中实现唯一性检查：如果您以共享模式读取数据，并且没有看到要插入的行的重复项，那么您可以安全地插入行并知道在读取过程中设置在行的后继键上的下一个键锁可以防止任何人同时为行插入副本。因此，下一个键锁定使您能够“ 锁定 ”表中不存在的东西。

可以禁用间隙锁定，如 第14.5.1节“InnoDB锁定”中所述。这可能会导致幻影问题，因为当禁用间隙锁定时，其他会话可以将新行插入到间隙中。

死锁是由于每个事务持有另一个需要的锁而导致不同事务无法继续的情况。因为两个事务都在等待资源变为可用，所以既不释放它拥有的锁。

当事务锁定多个表中的行时（通过诸如UPDATE或的 语句SELECT ... FOR UPDATE），可能会发生死锁 ，但顺序相反。当这些语句锁定索引记录和间隔的范围时，也会发生死锁，每个事务由于计时问题而获取一些锁而不是其他锁。有关死锁示例，请参见 第14.5.5.1节“InnoDB死锁示例”。

为了减少死锁的可能性，使用事务而不是LOCK TABLES语句; 保持插入或更新数据的事务足够小以至于不能长时间保持打开状态; 当不同的事务更新多个表或大范围的行时，请SELECT ... FOR UPDATE在每个事务中使用相同的操作顺序（例如 ）; 在SELECT ... FOR UPDATE和 UPDATE ... WHERE 语句中使用的列上创建索引。死锁的可能性不受隔离级别的影响，因为隔离级别改变了读操作的行为，而死锁因为写操作而发生。有关避免和从死锁状态恢复的更多信息，请参阅 第14.5.5.3节“如何最小化和处理死锁”。

当启用死锁检测（默认）并发生死锁时，InnoDB检测条件并回滚其中一个事务（受害者）。如果使用innodb_deadlock_detect 配置选项禁用死锁检测 ，则InnoDB依赖该 innodb_lock_wait_timeout设置来回滚死锁情况下的事务。因此，即使您的应用程序逻辑正确，您仍然必须处理必须重试事务的情况。要查看InnoDB用户事务中的最后一个死锁，请使用该 SHOW ENGINE INNODB STATUS命令。如果频繁死锁突出显示事务结构或应用程序错误处理的问题，请使用 innodb_print_all_deadlocks 设置启用将有关所有死锁的信息打印到 mysqld错误日志中。有关死锁如何自动检测和处理的更多信息，请参见 第14.5.5.2节“死锁检测和回滚”。

MySQL的> CREATE TABLE t (i INT) ENGINE = InnoDB;
查询OK，0行受影响（1.07秒）

MySQL的> INSERT INTO t (i) VALUES(1);
查询OK，1行受影响（0.09秒）

MySQL的> START TRANSACTION;
查询OK，0行受影响（0.00秒）

MySQL的> SELECT * FROM t WHERE i = 1 LOCK IN SHARE MODE;
+ ------ +
| 我|
+ ------ +
| 1 |
+ ------ +

MySQL的> START TRANSACTION;
查询OK，0行受影响（0.00秒）

MySQL的> DELETE FROM t WHERE i = 1;

MySQL的> DELETE FROM t WHERE i = 1;
错误1213（40001）：尝试获取锁定时发现死锁;
尝试重新启动事务

错误1213（40001）：尝试获取锁定时发现死锁;
尝试重新启动事务